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Abstract 



A classic problem in security is the problem of determining whether a given program has 
secure information flow . Informally, this problem may be described as follows: Given a pro- 
gram operating on public and private variables, check whether observations of the public vari- 
ables before and after execution reveal any information about the initial values of the private 
variables. Although the problem has been studied for several decades, most of the previous ap- 
proaches have been syntactic in nature, often using type systems and compiler data flow analysis 
techniques to analyze program texts. This paper presents a considerably different approach to 
checking secure information flow, based on a semantic characterization of security. A semantic 
approach has several desirable features. Firstly, it gives a more precise characterization of secu- 
rity than that possible by conservative methods based on type systems. Secondly, it applies to 
any programming constructs whose semantics are definable; for instance, nondeterminism and 
exceptions pose no additional problems. Thirdly, it can be applied to reasoning about indirect 
leaking of information through variations in program behavior (e.g., whether or not the program 
terminates). The method is also useful in the context of automated verification, since it can be 
used to develop a mechanically-assisted technique for checking whether the flow of a given 
program is secure. 
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0 Introduction 

A classic problem in security is the problem of determining whether a given computer program 
has secure information flow [BLP73, Den76]. In its simplest form, the problem may be described 
informally as follows: Given a program operating on "high-security" and "low-security" variables, 
check whether observations of the initial and final values of the low-security variables reveal any- 
thing about the initial values of the high-security variables. A related problem is that of detecting 
covert flows, where information may be leaked by variations in program behavior [Lam73]. For 
instance, it may be possible to conclude something about the initial values of the high-security vari- 
ables by examining the resource usage of the program (e.g., by counting the number of times it 
accesses the disk head). 

The problem of secure information flow is more important today than ever before, because more 
and more computers are becoming connected. The risk of information being leaked inappropriately 
is a concern in protecting high-security military and financial data as well as in protecting data 
stored on personal computers. For example, with the advent of the Web, there is a danger that a 
downloaded applet will leak private data (such as the contents of a local file) by communicating it 
to other sites. 

Most previous approaches to checking secure information flow have been syntactic in nature, 
often using type systems and compiler data flow analysis techniques to analyze program texts. In this 
paper, we present a considerably different approach to secure information flow, based on a semantic 
notion of program equality. A definition based on program semantics has several desirable features. 
Firstly, it provides a more precise characterization of secure information flow than that possible 
by conservative methods based on types. Secondly, it is applicable to any programming construct 
whose semantics are defined; for instance, nondeterminism and exception handling constructs pose 
no additional problems. Thirdly, it can be applied to reasoning about a variety of covert channels, 
including termination behavior and timing channels. Finally, the method is also useful in the context 
of automated verification, since it can be used to develop a mechanically-assisted technique for 
certifying program flow. 
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The outline of the rest of the paper is as follows. We start in section 1 by informally defining the 
problem and discussing several small examples. We present the formal characterization of security 
in section 2. In section 3, we relate our definition to a notion used elsewhere in the literature. In 
sections 4 and 5, we show how to rewrite our definition in the weakest precondition calculus so that 
it is amenable for use with tools for mechanical verification. Finally, we discuss related work in 
section 6 and give a short summary in section 7. 



1 Informal description of the problem 

Throughout this paper, we assume that for each program that we consider, the program variables are 
partitioned into two disjoint tuples h (denoting "high-security" variables) and k (denoting "low- 
security" variables). Informally, we say that a program is secure if: 

Observations of the initial and final values of k do not give any information about the 
initial value of h . 

We illustrate this notion with a number of program examples. 
The program 

k:=h 

is not secure, since the initial value of h can be observed as the final value of k . However, the 
program 

h:=k 



is secure, since k , whose value is not changed, is independent of the initial value of h . Similarly, 
the program 

k:=6 



is secure, because the final value of k is always 6 , regardless of the initial value of h . 

It is possible for an insecure program to occur as a subprogram of a secure program, 
example, in each of the four programs 



— h; k 

— k , k 
= h:k 



= 6 
= h 

= k-h 



For 



(0) 
(1) 
(2) 
(3) 



if false then k :— h end 

the insecure program k :— h occurs as a subprogram; nevertheless, the four programs are all secure 
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There are more subtle ways in which a program can be insecure. For example, 

if h then k :— true else k -.—false end 

is insecure, despite the fact that each branch of the conditional is secure. This program has the same 
effect as k :— h, but the flow of information from h to k is called implicit [Den76]. 

In the insecure programs shown so far, the exact value of h is leaked into k . This need not 
always be the case: a program is considered insecure if it leaks any information about h . For 
example, neither of the two programs 

k := h * h 

if 0 < h then k :— 1 else k :— 0 end 

transmits the entire value of h , but each of the programs is insecure because the final value of k 
does reveal some information about the initial value of h . 

A nondeterministic program can be insecure even if an adversary has no control over how the 
nondeterminism is resolved. For example, the following program is insecure, because the final value 
of k is always very close to the initial value of h : 

k:=h-l D k:=h+l 

(The operator D denotes demonic choice: execution of S D T proceeds by choosing any one of S 
or T and executing it.) The program 

skip D k := h 

is also insecure, because if the initial and final values of k are observed to be different, then the 
initial value of h is known. 

Finally, we give some examples of programs that transmit information about h via their ter- 
mination behavior. The nicest way to present these examples is by using Dijkstra's if fi con- 
struct [Dij76]. The operational interpretation of the program 

if BO — ► SO D SI — ► SI fi 

is as follows. From states in which neither BO nor Bl is true, the program loops forever; from all 
other states it executes either 50 (if SO is true) or SI (if SI is true). If both BO and Bl are true, 
the choice between SO and SI is made arbitrarily. Now, the deterministic program 

ifh - 0 — > loop Wh^O — > skip fi (4) 

(where loop is the program that never terminates) is insecure, because whether or not the program 
terminates depends on the initial value of h . In addition, each of the nondeterministic programs 

if h — 0 — > skip D true — > loop fi (5) 
if h = 0 — > loop D true — > skip fi (6) 
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is also insecure. Program (5) terminates only if the initial value of h is 0 ; even though there is 
always a possibility that the program will loop forever, if the program is observed to terminate, the 
initial value of h is known. Similarly, if an adversary is able to detect infinite looping, then the 
nontermination of program (6) indicates that the initial value of h is 0 . 

We hope that these examples, based on our informal description of secure information flow, 
have helped give the reader an operational understanding of the problem. From now on, we will 
adopt a more rigorous approach. We start in the next section by formally defining security in terms 
of program semantics. 

2 Formal characterization 

In this section, we give a formal characterization of secure information flow. As stated in the 
introduction, our characterization is expressed as an equality between two program terms. We use 
the symbol = to denote program equality and we write " S is secure" to mean that program S has 
secure information flow. 

A key ingredient in our characterization is the program 

"assign to h an arbitrary value" 

which we denote by HH ("havoc on h"). Program HH may be used to express some useful 
properties. Firstly, observe that the difference between a program S and the program HH ; S is 
that the latter executes S after setting h to an arbitrary value. Thus, the programs 5 and HH ; S are 
equal provided that S does not depend on the initial value of h . Secondly, observe that the program 
S ; HH "discards" the final value of h resulting from the execution of S . These observations help 
in giving an informal justification to the following definition of security. 

Definition 0 (Secure Information Flow) 

5 is secure = (HH ; S ; HH = S ; HH) (7) 

Using the two observations above, this characterization may be understood as follows. First, note 
that the final occurrence of HH on each side means that only the final value of k , not of h , is of 
interest. Next, observe that the prefix "HH ; " in the first program means that the two programs are 
equal provided that the final value of k produced by S does not depend on the initial value of h . 
In section 3, we provide a more rigorous justification for this definition, by relating it to a notion of 
secure information flow that has been used elsewhere in the literature; but, for now, we hope that 
this informal argument gives the reader an operational understanding of our definition. In the rest 
of this section, we discuss some of the features of our approach. 

Firstly, note that we have not stated the definition in terms of a particular style of program 
semantics (e.g., axiomatic, denotational, or operational). Sequential program equality can be ex- 
pressed in any of these styles [Hoa96] and different choices are suitable for different purposes. For 
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instance, in this paper, we will use a relational semantics to establish the correctness of our defini- 
tion, but we will use weakest precondition semantics to obtain a definition that is more amenable 
for use in mechanical verification. Secondly, observe that our definition is given purely in terms 
of program semantics; thus it can be used to reason about any programming construct whose se- 
mantics are defined. For instance, nondeterminism and exceptions (cf. [Cri84, LvdS94]) pose no 
additional problems in this approach, nor do data structures such as arrays, records, or objects 
(cf. [Hoa72, Lei97]). Finally, note that our definition leaves open the decision of which variables 
are deemed to be low-security (i.e., observable by an adversary). Different choices may be used to 
reason about different kinds of covert channels, by introducing appropriate special variables (such 
as those used by Hehner [Heh84]) and including them in the low-security variables k . For example, 
one can reason about timing channels by introducing in k a program variable that models execution 
time. 

3 Security in the relational calculus 

In this section, we justify our characterization of security by showing that it is equivalent to a 
notion used elsewhere in the literature. Since that notion was given in operational terms, we find 
it convenient to use a relational semantics. Thus, for the purposes of this section, a program is a 
relation over the state space formed by variables h and k . 

We use the following notational conventions. The identifiers w, x, y, z denote elements of a 
state space. We write x.k and x.h to denote the values of k and h in a state x . For any relation 
S and states x and y , we write x(S)y to denote that S relates x to y ; this means that there is an 
execution of program S from the pre-state x to the post-state y . The identity relation is denoted by 
Id ; it satisfies x(Id)y = x — y for all x and y . The symbol C denotes relational containment 
and the operator ; denotes relational composition. We will use the facts that Id is a (left and right) 
identity of composition and that ; is monotonic with respect to C in each of its arguments. 

We use the following format for writing quantified expressions [DS90] : For Q denoting either 
V or 3 , we write 

( Qj : r.j : t.j ) 

to denote the quantification over all t.j for all j satisfying r.j . We call j the dummy, r.j the range, 
and t.j the term of the quantification. When the range is true or is understood from context, we 
omit it. We use similar notation and conventions to define sets, by writing 

U ■ r.j : t.j } 

to mean the set of elements of the form t.j for all j satisfying r.j . 
The relational semantics of program HH are given by 

(Vx,y :: x(HH)y = x.k = y.k ) 
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Note that the relation HH is both reflexive and transitive: 



Id C HH (8) 
HH ; HH C ffi/ (9) 

Using these properties, condition (7) may be rewritten in relational terms as follows. 
5 is secure 

= { Security condition (7), program equality = is relational equality — } 

HH ; S ; HH = S ; HH 
=>• { (8) and ; monotonic, hence HH ; S ; Id ^ HH ; S ; HH } 

HH ;S C 5 ; HH 
=>■ { Applying " ; ffi/ " to both sides, using ; monotonic } 

HH ; 5 ; HH C S ; HH ; HH 
=>■ { (9) and ; monotonic } 

HH;S;HH C S ; ffif 
=» { (8) and ; monotonic, hence Id ; S ; HH <^ HH ; S ; HH } 

HH;S;HH = S ; HH 

Since the second and last lines are equal, we have equivalence throughout; thus, we have shown 

S is secure = (HH ; 5 C 5 ; HH) (10) 

This definition is useful because it facilitates the following derivation, which expresses security in 
terms of the values of program variables. 

HH ;S C S ;HH 

— { Definition of relational containment } 

(Vy.w :: y{HH; S)w y(S;HH)w) 

— { Definition of relational composition } 

(Vv,w:: (3x :: y(HH)x A x(S)w) (3 Z :: y(5)z A z(HH)w )) 
= { Relational semantics of HH , shunting between range and term } 

(Vy,w :: (3x :: y.k — x.k A x(S)w ) =>• (3z : y(5)z : z.^ = w./: )) 

— { Predicate calculus } 

(Vv,w :: (Vx :: y.k = x.k A x(S)w (3z : v(5)z : zJfe = wJfe ))) 

— { Unnesting of quantifiers } 

(Vx, y, w :: y.k - x.k A x(S)w (3z : y(S)z : z.k = w.k)) 

— { Nesting, shunting } 

(Vx,y : y.k = x.k : (Vw :: x{S)w (3z : y(5)z : zJfe = wJfe ))) 

— { Set calculus } 

(Vx,y : y.k = x.k : {w : x(5)w : wJfe } c {z : y(5)z : z.k }) 
= { Expression is symmetric in x and y } 

(Vx, y : y.k = x.k : {w : x(5)w : w.^ } = {z : y(5)z : z.^ }) 
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Thus, we have established that, for any S , 

S is secure = (Vx, y : x.k — y.k : {w : x{S)w : w.k } — {z : v(5)z : z.k }) (11) 

This condition says that the set of possible final values of £ is independent of the initial value of 
h . The condition has appeared in the literature [BBLM94] as the definition of secure information 
flow, and similar definitions for deterministic programs have been used elsewhere [VSI96, VS97b]. 
Thus, one may view the derivation above as a proof of the soundness and completeness of our 
characterization (7) with respect to the notion used by others. 

4 Security in the weakest precondition calculus 

In this section, we show how our definition of secure information flow may be written succinctly in 
the weakest precondition calculus [Dij76]. In section 5, we go one step further by showing how to 
write this weakest precondition formulation of security as a first-order predicate. 

We begin by introducing some useful notation. Recall that we are considering programs whose 
variables are partitioned by k and h . Thus, every predicate on the state space of such a program 
depends only on the variables k and h . We will use identifiers p and q to denote such predicates; 
for any such p we will write [p] (read "everywhere p") as an abbreviation for ( V k,h :: p ) . 
For any program 5 , the predicate transformers wlp.S ("weakest liberal precondition") and wp.S 
("weakest precondition") are informally defined as follows [Dij76]: For any predicate p , 

wlp.S. p holds in exactly those initial states from which every terminating computation 
of S ends in a state satisfying p , and wp.S.p holds in exactly those initial states from 
which every computation of S terminates in a state satisfying p . 

The two predicate transformers are related by the following pairing property [Dij76]: For any pro- 
grams S and T, 

(V/? :: [wp.S.p = wlp.S.p Awp.S.true]) (12) 

The predicate transformer wlp.S is universally conjunctive, that is, it distributes over arbitrary 
conjunctions. Universal conjunctivity implies monotonicity [DS90]. The wlp and wp semantics 
of the program HH are: 

(Wp :: [wlp.HH.p = (VA :: p )] ) 
[wp.HH.true = true] 

Program equality in the weakest precondition calculus is defined as the equality of wp and wlp on 
each predicate; thus 

S = T = (Wp :: [wlp.S.p = wlp. T.p] A [wp.S.p = wp.T.p] ) 
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which, on account of the pairing property, can be simplified to 

S = T = (Vp :: [wlp.S.p = wlp.T.p] ) A [wp.S.true = wp.T. true] 

Using this definition of program equality, we now rewrite security condition (7) in the weakest 
precondition calculus as follows. 

HH ; 5 ; HH = S ; HH 
= { Program equality in terms of wlp and wp } 

(Vp :: [wlp.(HH ; S ; HH).p = wlp.{S ; HH).p] ) 
A [wp.(HH ; S ; HH).true = wp.(S ; HH).true] 
= { wlp and wp of HH and ; } 

(Vp :: [(Vfc :: wlpJ5.(Vh :: p )) = wlp.S.{Vh :: /? )] ) (13) 
A [(V/i :: wp.S.true) = wp.S.true] (14) 

The last formula above contains expressions having the form of a predicate g satisfying 
[(Vft :: 3) = $] 

Predicates with this property occur often in our calculations, so it will be convenient to introduce 
a special notation for them and identify some of their properties. This is the topic of the following 
subsection. 



4.0 Cylinders 

A predicate q that satisfies [q = (V/i :: q )] has the property that its value is independent of the 
variable h . We shall refer to such predicates as " h -cylinders", or simply as "cylinders" when h is 
understood from context. For notational convenience, we define the set Cyl of all cylinders: 

Definition 1 (Cylinders) For any predicate q , 

qeCyl = [q = (Vft :: q )] (15) 

The following lemma provides several equivalent ways of expressing that a predicate is a cylinder. 

Lemma 0 For any predicate q, the following are all equivalent. 

i. q e Cyl 

ii. [q = (Vh :: q)] 
Hi. [q ( V h : : q )] 

iv. (Sp :: [q = (Vft ::/>)]) 

v. —>q e Cy/ 

Proof. Follows from simple predicate calculus. □ 
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4.1 Security in terms of cylinders 

We now use the results in the preceding subsection to simplify the formulation of security in the 
weakest precondition calculus. We begin by rewriting (13) as follows. 

(Vp :: [(Vfc :: wlp.S.(Vh :: p )) = wlp.S.{Vh :: p )] ) 
{ Definition of CyZ (15) } 

(Vp :: wlp.S.(Vh :: p ) e Cyl ) 
= { One-point rule } 

(V/7,4 : [<? = (V/i :: p)] : wlp.S.qeCyl) 
= { Nesting and trading } 

(Vq :: (V/? :: = (Vfc ::/?)] wlp.S.qeCyl)) 
= { Consequent is independent of p } 

(Vq :: (3/7 :: [q = (Vh :: p)]) wlp.S.qeCyl) 
= { Lemma O.iv, and trading } 

( V q : q e Cyl : wlp.S.q e Cyl ) 

Similarly, we rewrite the expression (14) as follows. 

[(V/i :: wp.S.true) = wp.S.true] 
= { Definition of Cyl (15) } 

wp.S.true e Cyl 

Putting it all together, we get the following condition for security: For any program S , 

5 is secure = (Vp : p e Cyl : wlp.S.p e Cyl ) A wp.S.true e Cyl (16) 

5 A first-order characterization 

Checking whether a given program S is secure using condition (16) given in the previous section 
involves checking that certain predicates are cylinders; this can be done with a theorem prover. 
(Checking whether a given predicate is a cylinder can also be done by the considerably cheaper and 
more conservative method of syntactically scanning the predicate for free occurrences of h .) Thus, 
checking the second conjunct on the right-hand side of (16) is straightforward. However, checking 
the first conjunct, namely 

(Vp : peCyl : wlp.S.p e Cyl ) (17) 

involves a quantification over predicates; thus, it is not well-suited for automated checking (nor does 
the syntactic scan for free occurrences of h work). In this section, we show how this higher-order 
quantification over p can be reduced to a first-order quantification over the domain of k . 

To explain how the reduction is brought about, we need two new notions, namely that of con- 
junctive and disjunctive spans. Informally speaking, for any set X of predicates, the conjunctive 
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(disjunctive) span of X , denoted A.X (S.X), is the set of predicates obtained by taking conjunc- 
tions (disjunctions) over subsets of X . The main theorem of this section asserts that the range of p 
in the quantification (17) above may be replaced by any set of predicates whose conjunctive span is 
the set Cyl . The usefulness of the theorem is demonstrated in subsection 5.1, where we show that 
there exist small sets of predicates whose conjunctive span is Cyl . 

We will use the following notational conventions in this section. For any set X of predicates, 
we write —>X to mean the set { q : q e X : ->q } . We also write V.X to mean the conjunction of 
all the predicates in X , and 3.X to mean the disjunction of all the predicates in X . Note that, as a 
result of these conventions, we have [->(V.Z) = 3.(->X)] . 

5.0 Spans 

For any set X of predicates, we define sets A.X and £.X as follows. 

Definition 2 (Spans) 

AX = { XS : XS C X : V.Z5 } 
e.X = {XS : XS Q X : 3.XS} 

The two notions are related by the following lemma, whose proof follows from simple predicate 
calculus. 

Lemma 1 For any set X of predicates, 

^ex = a.(-x) 

We are now ready to present the main theorem of this section, which states that one can establish 
the quantified expression 

{Vq : qe AX : f.q e Cyl ) 

by establishing a quantified expression over a smaller range. 

Theorem 0 Let f be a universally conjunctive predicate transformer and let X be any set of pred- 
icates. Then 

(Vp : p eX : f.p e Cyl) = (V q : q e AX : f.q € Cyl ) 

Proof. Note that the left-hand side follows from the right-hand side, since X C A.X ; thus, it 
remains to prove the implication 

( Vp : p eX : f.p eCyl) (V? : q e AX : f.q e Cyl ) 

We prove this implication by showing that for any predicate q in A.X , the antecedent implies that 
f.q is a cylinder. So, let q be any predicate in A.X . By the definition of a conjunctive span, there 
is a subset XS of X such that [q = V.X5] . Observe: 
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(Vp : P eX :f.peCyl) 
=>■ { IKI, antimonotonicity of V in its range } 

(Vp : peXS : f.peCyl) 
= { Lemma O.iii } 

(Vp : peXS : [f.p (Vft :: /.p )] ) 
=>■ { / is universally conjunctive, hence monotonic, also [V.XS =>• p] } 

(Vp : peXS : [f.(V.XS) ( V/! :: /.p )] ) 
= { Range p e XS is independent of k and h } 

[( Vp : p e XS : /.(V.XS) =» ( V/! :: /.p ))] 
= { Antecedent is independent of p } 

[f.(VXS) (Vp : p e XS : (Vft :: /p ))] 

— { Interchange quantifications, range p e XS is independent of h } 
\f.(V.XS) (Vft :: (Vp : p e XS : /.p ))] 

— { / is universally conjunctive } 
[f.(V.XS) (Vft :: /.(Vp : p e XS : p ))] 

— { Notation " V. " described above } 
\f.(V.XS) (Vfc ::/.(V.XS))] 

— { Lemma O.iii } 
/.(V.XS) e CvZ 

— {By assumption, [g = VXS] } 
f.q e Cyl 

□ 



From the standpoint of mechanical verification, the usefulness of the result above is due to the 
fact that there are sets of predicates much smaller than Cyl whose conjunctive span is Cyl . In 
the following subsection, we show such a set of predicates whose cardinality is the same as the 
cardinality of the domain of k . 

5.1 A lower-order quantification 

Consider the following two sets of predicates, where K ranges over the set of possible values of the 
variables k. 

PP — {K :: k — K } (18) 
NN = {K :: k^K} (19) 

It follows directly from these definitions that 

PP = -.AW (20) 

The relationship of these sets to Cyl is given by the following lemma. 
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Lemma 2 With PP and NN as defined above, we have 

i. S.PP = Cyl 

ii. A.NN = Cyl 

Proof. We give an informal sketch of the proof here; details are left to the reader. By definition, Cyl 
consists of exactly those predicates that are independent of h , that is, they depend on the variable 
k only. But every predicate on k may be written as a disjunction of predicates, one for each value 
in the domain of k ; thus part (i) follows. Part (ii) follows directly from part (i), observation (20), 
Lemma 1, and Lemma O.v. □ 

Using the fact that wlp.S is universally conjunctive for any statement S , and Lemma 2.ii, we 
apply Theorem 0 with /, X :— wlp.S, NN to obtain the following result. 

5 is secure = (V q : q e NN : wlp.S. q e Cyl) A wp. S. true e Cyl. 

Using the definition of AW (19), this may be further simplified to the following. 

S is secure = (V K :: wlp.S. (k + K) e Cyl ) A wp. S. true e Cyl (21) 

Note that this is simpler than (16) since the range of the quantification is the domain of k . Thus, in 
particular, security according to (21) is stated as a first-order formula. 

5.2 Deterministic programs 

In the case that 5 is also known to be deterministic, we can simplify the security condition (21) 
even further. A deterministic program S satisfies the following properties [DS90]: 



Consequently, the term involving wp in (21) is subsumed by the term involving wlp : 

wp.S.true e Cyl 
= { (22), with p :— true } 

-•wlp.S. false e Cyl 
= { Lemma O.v } 

wlp.S.false e Cyl 

{ false e Cyl } 

(Vg : q e Cyl : wlp.S. q G Cyl ) 



(V/? :: [wp.S.p = -*wlp .S .(—ip)] ) 
wp.S is universally disjunctive 



(22) 
(23) 
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Thus, the security condition for deterministic S is given by 



S is secure = (V K :: wlp.S.(k # K) e Cyl ) (24) 

Next, we show that condition (24) may also be expressed in terms of wp and PP instead of 
wlp and AW. 

( W q : q e Cyl : wlp.S.q G Cyl ) 

= { Theorem 0 } 

(Wq : qeNN : wlp.S.q e Cyl ) 

= { Negation is its own inverse, so rename dummy q to ->p } 

(Wp : ->/? e NN : wlp.S.(^p) e Cyl ) 

= { Observation (20), and (22) } 

(Wp : pePP : ^wp.S.p e Cyl ) 

— { Lemma O.v } 

(Wp : pePP : wp.S.p e Cyl) 

Thus we have another way of expressing the condition for security of deterministic programs, 
namely, 

S is secure = (W K :: wp.S.(k — K) e Cyl ) (25) 



5.3 Examples 

We give some examples to show our formulae at work. 
Firstly, consider the secure program (2). We calculate, 

(k :— h ; k :— k — h) is secure 

— { Security condition (21) } 

(WK :: wlp.(k:=h; k := k - h).(k + K) e Cyl) 
A wp.(k := h ; k := k — h).true G Cyl 
= { wlp and wp of := and ; } 

( WK :: (h-h^K) eCyl) A true e Cyl 

— { Lemma O.ii, and true e Cyl } 

(WK :: [h-h^K = ( Wh :: h - h ^ K )] ) 

— { Arithmetic } 

(WK :: [O^K = (Wh :: 0 ^ K )] ) 

— { Predicate calculus } 
true 

This shows that our method does indeed establish that program (2) is secure. 

Secondly, we apply the security condition to program (5), which is insecure because of its 
termination behavior. 
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(if h — 0 — > skip D true — > loop fi) is secure 
— { Security condition (21) } 

( VA" :: wlp.{\fh = 0 — ► skip D true — ► loop fi).(Jfc # A) e CyZ ) 

A vvp.(if h — 0 — >• skip D frwe — >• loop R).true e Cyl 
= { wlp and wp , 

using (Vjo :: [wlp.loop.p = true]) and [wp.loop.true = false] } 
(VK :: ((ft = 0 k^K) A (frae => true)) e Cyl) 

A ((/i — 0 v frwe) A (A = 0 =>• frwe) A (frwe => false)) e Cyl 
= { Predicate calculus } 

( VK :: (A = 0 =► k^K) eCyl) A J&Jse e CyZ 
= { Lemma O.ii, and /aZse e Cyl } 

(VK :: [A = 0 k ^ K = (Vft :: 6 = 0 Zc # A )] ) 
= { [p] is shorthand for ( V fc, /i : : p ) } 

(VK,k,h h = Q => k^K = (Vh:: h = 0 =» k ^ K )) 
=>• { Instantiate with K, k, h := 2,2,2 } 

2 = 0 =>■ 2^2 = (Vh :: h = 0 =>■ 2^2) 
= { Arithmetic and predicate calculus } 

(Vfc :: A ^ 0) 

{ Instantiate h :— 0 } 

false 

Finally, using program (4), we illustrate how one can reason about secure termination behavior 
of deterministic programs using w/p . 

(if /i — 0 — >• Zoo/? D /i 7^ 0 — >• skip fi) is secure 
= { Security condition for deterministic programs (24) } 

(WK :: wlp.(jth = 0 — ► Zoo/? D h + 0 — ► stop fi).(Zc ^ K) e Cyl ) 
{ wlp } 

(VK :: ((ft = 0 =>■ true) A (h # 0 =>■ k ^ K)) e Cyl ) 
= { Definition of CyZ , since /i^O k ^ K is not independent of Zi } 

/aZse 

6 Related work 

The problem of secure information flow has been studied for several decades. A frequently used 
mathematical model for secure information flow is Denning's lattice model [Den76], which is based 
on the Bell and La Padula security model [BLP73]. Static certification mechanisms for secure 
information flow, an area pioneered by Denning and Denning [Den76, DD77], seem to fall into two 
general flavors: type systems and data flow analysis techniques. In this section, we discuss each of 
these and compare them to our work. A historical perspective on secure information flow can be 
found, for example, in a book by Gasser [Gas88]. 



13 



6.0 Type systems approach 

The static certification mechanism proposed by Denning and Denning [DD77] can be described as 
a type checker for secure information flow. Each variable x occurring in a program is declared to 
have a particular security class, or type, written class.x . These security classes are related by a 
given lattice ordering < . The type checker computes the type of an expression as the lattice join of 
the types of its subexpressions. For example, 

class.{E + F) = class.E f class. F 

Each program statement also has a security class, computed as the lattice meet of the security classes 
of the statement's 1-expressions. For example, 

class. (x \—E) = class. x 

class.(if E then S else T end) — class.S j. class.T 
The type checker certifies a program S as being secure only if: 

0. for every assignment statement x := E in S , class.E < class. x , and 

1. for every conditional statement if E then T else U end in S, class.E < class.T and 
class. E < class. U . 

Other programming constructs, such as loops, give rise to similar requirements. 

Denning and Denning gave an informal proof of the soundness of their certification mechanism, 
that is, a proof that the mechanism certifies only secure programs. Recently, Volpano et al. have 
given a more rigorous proof thereof [VSI96, VS97b]. 

The advantage of using a type system as the basis of a certification mechanism is that it caters 
for a simple implementation. However, because of the nature of type systems, this certification 
mechanism rejects any program that contains a subprogram that by itself would be insecure. But 
as we saw in examples (0)-(3) of section 1 , an insecure program can occur as a subprogram of a 
secure program. In contrast, our approach does recognize programs like (0)-(3) as being secure. 

Also, just like it would be too much to hope for a useful type system that would reject programs 
that may fail to terminate, it would be too much to hope for a useful type system that would reject 
programs that may leak information via their termination behavior. (Volpano and Smith [VS97a] 
have attempted such a type system; however, their type system rejects any program that mentions h 
in a loop guard, which can be construed as resigning the game before it starts.) 

6.1 Data flow analysis approach 

Just like there are data flow analysis techniques that let an optimizing compiler analyze a given pro- 
gram beyond type checking [ASU86], there are data flow analysis techniques for secure information 
flow. The idea is to conservatively find the program paths through which data may flow. 
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We choose to present the data flow analysis approach to secure information flow as a translation 
from a given program 5 to a program 5' that captures and facilitates reasoning about the possible 
flows of 5 . For every variable x of 5 , program 5" instead contains a variable x , representing 
the security class of the value dynamically computed into x . To deal with implicit flows, 5" also 
contains a special variable local , representing the security class of the values used to compute the 
guards that led execution to the current instruction. We describe the translation by example. For 
every assignment statement of the form x :— y + z in 5 , 5' contains a corresponding statement 

x := y f z t local 

where, as in the previous subsection, f denotes the lattice join on the set of security classes. For 
every conditional statement 

if x = y — ► 50 D z < 0 — ► 51 fi 

in 5 , 5" contains a corresponding statement 

var old :— local in 

local := local f x f y f z 
; if true — ► 50' D true — ► 51' fi 
; local := old 
end 

where 50' and 51' are the statements in 5' that correspond to 50 and 51 . If a program 5 has the 
variables k and h belonging to the security classes low and high (denoted _L and T , respectively, 
where _L < T ), then " 5 is secure " can be expressed as the following Hoare triple on 5' : 

{£<±a/i<Ta local < J_ } 5' { k < J- } (26) 

The first data flow analysis approach of this kind was given by Andrews and Reitman [AR80], 
whose treatment also dealt with communicating sequential processes. Banatre et al. [BBLM94] 
used a variation of the method described above that attempts to keep track of the set of initial vari- 
ables used to produce a value rather than only the security class of the value. They also developed 
an efficient algorithm for this approach, akin to data flow analysis algorithms used in compilers, 
and wrestled with a proof of soundness for the approach. (Contrary to what our description of 
the approach above may suggest, Andrews and Reitman used an ordinary if then else construct 
rather than Dijkstra's if fi construct. Banatre et al. used the if fi construct, but, as Volpano et al. 
point out, their soundness theorem is actually false for programs that make use of the nondetermin- 
ism [VSI96].) 

The data flow analysis approach can offer more precision than the type system approach. For 
example, the approach will certify the programs (0) and (1). However, the approach still rejects 
some secure programs that our approach will certify. This comes about because of two reasons. The 
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first reason is that the semantics of operators like + and — are lost in the rewriting of S into 5' . 
Thus a program like (2), which is secure on account of that h — h — 0 , is rejected by the data flow 
analysis approach. The second reason is that guards are replaced by true in the rewriting of S into 
5" . Thus, a program like (3) whose security depends on when control can reach a certain statement 
is rejected. 

A way to reduce rejections of secure programs that result from the second of these reasons, one 
can combine the data flow analysis approach with a correctness logic, as mentioned by Andrews and 
Reitman [AR80] : Instead of rewriting program S into S' , one can superimpose the new variables 
(k,h, local ) and their updates onto program S , and then reason about S using the Hoare triple 
(26) but on S instead of on 5" . A consequence of this combination with a correctness logic is that 
one can rule out some impossible control paths, such as the one in program (3). 

7 Summary 

We have presented a simple and novel mathematical characterization of what it means for a program 
to have secure information flow. The characterization is general enough to accommodate reasoning 
about a variety of covert channels. Unlike previous methods like type systems and compiler data 
flow analysis techniques, the characterization is in terms of the semantics of the program. Conse- 
quently, our method is more precise, and can therefore certify more secure programs, than previous 
methods. 

We showed an application of our security characterization with a weakest precondition seman- 
tics, deriving a first-order predicate whose validity implies that an adversary cannot deduce any 
secure information from observing the public inputs, outputs, and termination behavior of the pro- 
gram. As far as we know, our approach is the only one that can analyze termination behavior in a 
useful way and is also the only one that handles nondeterminism correctly. 

Future work includes employing our method in practice, and investigating the utility of our 
method in other areas, such as program slicing [Wei 84]. 
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